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REMARKS 

The following is in response to the non-final Office Action dated April 7 5 2004. The 
Applicant hereby requests that this case be reconsidered in light of the following. 

STATUS OF CLAIMS 

Claims 1-19 were pending. 
Claim 20 is newly added. 
Accordingly, Claims 1 -20 are pending. 

CLAIM REJECTIONS 

In Section 5 of the Office Action, Claims 1-19 were rejected under 35 U.S.C. § 103(a) as 
being unpatentable over U.S. Pat. No. 5,615,367 to Bennett et al. ("Bennett") in view of U.S. Pat 
No. 6,643,493 to Kilgore ("Kilgore"). In response, the Applicant respectfully submits that the 
Examiner has not established a prima facie case of obviousness in regards to Claims 1-19, and, 
therefore, that these claims are allowable. 

CLAIM 1 

As the Examiner is aware, to establish a valid prima facie showing of obviousness: (i) 
each and every element and limitation of the invention as claimed must be shown or suggested in 
the combined references; (ii) there must be some motivation to combine the references; and (iii) . 
there must be a reasonable expectation of success in combining the references. See M.P.E.P. § 
2143 (May 2004). Here, since neither Bennett nor Kilgore show or suggest either: (i) a 
denormalized database; or (ii) unique student identifiers contained in a master student table and 
related data tables linked to the master student table, as recited in Claim 1, these references fail 
to show or suggest all the elements and limitations of Claim 1 . Additionally, the Examiner has 
failed to set forth a showing, based on Kilgore and Bennett or otherwise, of why one of ordinary 
skill in the art would have been motivated to combine Kilgore and Bennett to arrive at the 
presently-claimed invention. 
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The Bennett patent discloses a relational database 155 (see FIG. IB) that includes "design 
documents 55 366, 371 (see FIGS. 3C-3E) that allow a user to customize how data is 
presented/displayed when accessing the database. To facilitate creating design documents, a data 
modeling module 130 is provided (see FIGS. 4A-4F). The data modeling module 130 is an 
interface where the user graphically selects data tables for inclusion in a design document and 
then graphically links the tables to one another (i.e., the graphical "link 55 establishes an indication 
of the user's desire for there to be a relation or logical link between the two tables). Once the 
user graphically signifies that two tables are to be linked together, the data modeling module 
follows an internal procedure for attempting to logically link the two tables together (see FIGS. 
7A-8B). For example, the module may: (i) determine a unique key for one of the tables; (ii) 
determine if a foreign key relationship exists between the selected tables, as would enable the use 
of an existing link; (iii) if there is no foreign key relationship, compare the unique key to the 
index (or indexable fields) of the other table, to determine possible links/relationships; and (iv) 
graphically display the derived, suggested link(s) to the user, for acceptance or rejection. 

Like most other relational databases, the system in Bennett utilizes a normalized data 
structure for reducing error and providing more flexibility in analysis. See Bennett, Col. 3, lines 
6-24; Col. 6, lines 58-65; Col. 16, lines 60-67. This means that: (i) the database uses many 
smaller tables with fewer fields; (ii) redundant fields are eliminated by mapping all the fields in 
each data table; and (iii) each table must be linked through an index of another table instead of 
directly to that table. In fact, the purpose behind the "automatic, 55 GUI-based table linking 
system in Bennett is to largely eliminate the need for users to become practiced in normalizing 
databases - instead, the system "does it for you. 55 See Bennet, Col. 3, lines 24-48 ("What is 
needed is a system and methods whereby ordinary end users, particularly those with no data 
processing experience or training, may apply the relational approach to a database management 
problem in a simple, intuitive fashion. ...[S]uch a system should provide tools for automating 
the task of data modeling in a relational database system. 55 ) 

Kilgore discloses a database for registering students in courses and generating, collecting, 
processing, and reporting student performance. See Kilgore, Col. 2, lines 56-60. The process 
utilizes a normalized relational (SQL) database to store information related to students in which 
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each student is assigned a "Unique Student ID". See Kilgore, Col. 4, lines 16-17; also, notice in 
the figures in Kilgore the lack of repeated fields that do not contain linking information, which 
indicates a normalized database. Information such as the student's name, sex, address, phone 
number and e-mail address are associated with the Student ID. The database consists of a 
normalized collection of data tables, the predetermined layout of which is shown in FIG. L 
(That is, where a database designer would normally start by first "roughing out" a database and 
then normalizing the database, Kilgore provides a database layout that is already normalized). 
Each table has a unique name. See Kilgore, Col. 3, lines 34-39. 

Like Bennett and Kilgore, the present invention relates to a computer database, in this 
case for tracking/storing student information. However, contrary to Bennett and Kilgore, the 
present invention utilizes an adaptable, modified star schema database having a denormalized 
structure. That is, instead of having a number of smaller tables linked to one another, and with 
few or no redundant fields, the database of the present invention: (i) is purposefully 
denormalized, i.e., not optimally divided into smaller tables each with fewer, non-redundant 
fields; (ii) may have many redundant data fields, i.e., redundant fields other than fields 
containing linking information; and (iii) utilizes a centralized master table (the master student 
table 12) that acts as the hub of the database, i.e., various table "branches" are linked to the 
master table by common student identification codes but are not modified to match or correspond 
to the master student table 12. 

To elaborate, as shown in FIG. 1, at the core of the present invention is the master student 
table 12. The master student table 12 includes a plurality of records, each of which relates to a 
single student, and each of which typically contains student name and student identification 
fields. A number of related data tables 22, 24, 26 are linked directly to the master student table 
12 by way of the student identification codes, i.e., the related data tables 22, 24, 26 have a 
student identification field linked to the student identification field of the master student table 12. 
Where necessary, other related data tables are linked to the master student table 12 by linking 
tables 52. The linking tables 52 contain a field for the student identification, as well as a field for 
concatenated identification codes (code strings comprising several relevant shorter codes chained 
together) which define links to downstream tables. For populating the database, all data is 
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loaded directly from needed tables in a denormalized manner, wherein the needed tables are not 
modified to match or correspond to the master student table. "This permits all data to be loaded 
regardless of condition or degree of completeness allowing the use of the system 10 and 
determination at a later time about what data should be cleaned up or added." Page 6, lines 9-19. 

Having a denormalized database with a modified-star data structure (a centralized master 
table to which related data tables are linked by way of identification codes or concatenated 
identification codes) provides many benefits. First, unlike normalized databases, there is no need 
to map all incoming data to an intermediate database, and to then clean and load the data to a 
final, target database. Instead, this step is bypassed entirely, in favor of source data being 
mapped directly to target data with possible redundant fields, etc. Thus, as mentioned above, 
preexisting school system data can be loaded regardless of the condition or degree of 
completeness of the data and data types. See Page 4, lines 1-15. 

Additionally, since there is no rigid, fixed-target data model, no changes to the 
foundational database are required to accommodate new data types. In fact, new data types can 
be easily integrated into the final target database without additional redesigns or added costs. 
Despite this, the core design (master student table 12, related data tables linked by way of linking 
tables or student identifications) does not change from installation to installation, meaning that 
while the database of the present invention is adaptable, it is static enough to allow for 
efficiencies in data builds and in creating standardized reports. See Page 4, lines 1-15. 

Finally, there is no need to map data table fields for normalization, which adds time and 
expense to implementing a functioning system, and drill-down and data mining capabilities are 
enhanced. See Page 4, line 3 1 -Page 5, line 12. 

Claim 1 is directed to a denormalized database. While "denormalized" is only recited in 
the preamble, since it does not relate to function or intended purpose, but instead defines the 
claimed invention structurally, it is believed relevant to a determination of patentability. See 
M.P.E.P. § 21 1 1.02 (May 2004)("Any terminology in the preamble that limits the structure of 
the claimed invention must be treated as a claim limitation.") In light of the above, it should be 
apparent that neither Bennett nor Kilgore disclose, suggest, or otherwise relate to denormalized 
databases. Instead, in Bennett data tables are automatically linked in a normalized database by 
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comparing unique keys from one table to the index of another table, to obviate the need for a 
user to manually normalize or otherwise optimize the database. Similarly, while Kilgore relates 
to tracking student progress, it only discloses a normalized database. As such, since the cited 
references fail to disclose or suggest each and every element and limitation of Claim 1, Claim 1 
is believed allowable. 

In further regards to Claim 1 , on page 4 of the Office Action the Examiner states that 
while "Bennett does not teach a unique identifier corresponding to each student and an unique 
identifier corresponding to each student in a table. . ., Kilgore teaches a unique identifier 
corresponding to each student (col. 4, lines 15-20) and an unique identifier corresponding to each 
student in a table (col. 4, lines 15-27." While the Applicant agrees that Kilgore teaches a unique 
identifier to each student in a table, neither Kilgore nor Bennett disclose a database having 
unique student identifiers where those unique student identifiers are contained in both a master 
student table and in a plurality of related data tables linked to the master student table, as recited 
in Claim 1 . 

In particular, as discussed above, unique identifiers (either a student identification or a 
concatenated identifier) are used in the present database as means for linking the master student 
table and related data tables. The master student table includes a field with the student 
identifications, and each and every one of the related data tables includes a field with either the 
student identifications or concatenated identifiers uniquely related to the student identifications 
via linking tables. This facilitates the use of a denormalized database design according to the 
present invention. See Page 7, lines 16-29; Page 8, line 14-Page 9, line 20. 

In Bennett, on the other hand, while there may be a unique identifier as noted at Col. 9, 
lines 1 8-20, there is no teaching that this unique identifier is used in a master data table and all 
related data tables. Instead, since Bennett utilizes a normalized database design, as discussed 
above, only pairs of directly-linked tables will typically have common data fields, and it is 
certainly the case that all the data tables will not have fields for unique identifiers. (The very 
point of database normalization is to eliminate redundant fields and to break down a database's 
structure into a number of smaller tables that only have as many fields as necessary to establish a 
primary key.) Similarly, while Kilgore may show a database with unique student identifiers, the 
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unique identifiers are not included in a master table and all related data tables. By comparing the 
different tables in FIG. 1 in Kilgore, it can be seen that Kilgore is using a normalized approach, 
and that only a couple of the tables have a field for a "unique identifier corresponding to each 
student." 

It should be noted that while Kilgore mentions that "the tables share a key data element 
that is used to link the tables together" (Col. 3, lines 38-39), this is merely referring to directly- 
linked tables in a normalized database, where pairs or small groups of fields may have common 
fields containing linking data, and not to all the tables in a database having a shared or related 
unique identifier. This can be seen by referring to FIG. 1 and to Col. 3, line 60-Col. 4, line 39 in 
Kilgore, where it is noted that various groups of tables contain shared ID codes, which is typical 
in a normalized database. For example, table 12 has a "Hospital ID" which "is used to 
association information in table 12 with data in other tables" (Col. 3, line 66-Col. 4, line 3), 
while table 14 includes a faculty ID "which is used to relate the data in table 14 to the data in 
other tables." Col. 4, lines 4-14. All the tables in the database do not include a common or 
related code. 

Since Bennett and Kilgore fail to show or suggest a database with: (i) a master student 
table with "at least one unique identifier corresponding to each student"; and (ii) a plurality of 
related data tables each having the unique identifier corresponding to each student, as recited in 
Claim 1, Claim 1 is believed further allowable over Bennett and Kilgore in combination. 

As mentioned above, to establish obviousness, there must be some suggestion or 
motivation in the prior art to combine the references to arrive at the claimed invention. See 
M.P.E.P. § 2143.01. Here, it is respectfully submitted that there is no such motivation or 
suggestion in Bennett and Kilgore, and, therefore, that Claim 1 is further allowable over these 
two references combined. 

As discussed above, Bennett, in effect, relates to a means for semi-automating database 
normalization, while Kilgore relates to a specialized normalized database for evaluating medical 
students' progress and performance. As such, these references inherently fail to suggest that they 
be combined to arrive at the invention in Claim 1, since combining them would still not result in 
a denormalized database. Moreover, where Kilgore "spells out" the structure of a particular 


11 of 14 


Application No. 10/036,132 

Amdt Dated 07/16/04 

Reply to Office Action of 04/07/04 


database for achieving its student evaluation process (see FIG. 1 in Kilgore), there would have 
been no need for combining the system in Kilgore with the one in Bennett, which is for purposes 
of helping users to build their own databases from scratch. In other words, the functionality 
offered in Bennett would be largely extraneous or useless in the system in Kilgore. 

In Page 4, paragraph 3 of the Office Action, the Examiner states that "[i]t would have 
been obvious to one of ordinary skill in the art at the time the invention was made to combine the 
data tables of Bennett's method with the data table of Kilgore's method because Kilgore's data 
tables consist of sharing a key data element that is used to link the tables together. . . However, 
even to the extent some of the data tables in Kilgore share a key data element that is used to link 
the tables together, this provides no motivation to one of ordinary skill in the art to combine 
Kilgore and Bennett, since Bennett relates to an automatic process where such links are derived 
and suggested to the user. In other words, where Bennett takes two designated tables and 
attempts to automatically derive a logical link between them, Kilgore's alleged teaching of 
having shared key data elements for linking tables is irrelevant. 

Since Bennett and Kilgore fail to suggest a motivation for one of ordinary skill in the art 
to have combined them to arrive at the present invention as recited in Claim 1 , Claim 1 is further 
believed allowable over the Bennett and Kilgore references. 

CLAIMS 2-19 

Claims 2-19 all depend, either directly or indirectly, from independent Claim 1 . As such, 
Claims 2-19 are believed allowable as depending from an allowable base claim, for the reasons 
discussed above. However, the Applicant further notes that many of the additional 
elements/limitations found in Claims 2-19 are neither shown nor suggested in Kilgore and 
Bennett, and, therefore, that Claims 2-19 are believed further allowable over Kilgore and Bennett 
in combination, irrespective of the status of Claim 1 . 

Claim 2 depends from Claim 1 , and recites "a plurality of test results tables wherein each 
test results table represents a single standardized test event; and... wherein each test results table 
is individually linked to the master student table." While the Examiner states in Section 2 of the 
Office Action that Kilgore discloses such a feature, the Applicant respectfully submits that this is 
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not the case. More specifically, while Kilgore teaches tables containing test data (Col. 5 3 lines 1- 
11), these tables are not "individually linked to [a] master student table." Instead, as shown in 
FIG. 1, the test result-related tables 30, 32, 34 are linked to various other tables 26, 28 (none of 
which are a "master student table") in a conventional normalized manner. 

Further, Claims 3 and 9-19 all include a "linking table" containing "a concatenated 
identification code corresponding to each student identification code." As set forth in the present 
application at Page 8, lines 14-27, the purpose of the linking tables and concatenated 
identification codes is to establish a link pathway between the master student table and 
downstream, related data tables, where necessary. Each concatenated identification code 
comprises a chained-together list of various other codes, for example a school number, a student 
link code, and a sequence code. The concatenated identification codes, in addition to being 
included in the downstream, related data tables, are associated with the student identification 
numbers in the linking tables. This establishes a link pathway from the master student table to 
all downstream tables, even though the downstream tables are not normalized. 

Contrariwise, neither Bennett nor Kilgore show or suggest concatenated (chained- 
together) identification codes as contemplated in the present invention and recited in the claims. 
In fact, because both Bennett and Kilgore relate to normalized databases where "adjacent" data 
tables are logically linked together by way of common data fields, there is no need for 
concatenated identification codes across multiple linked data tables. Moreover, while the 
Examiner indicated that Bennett discloses concatenated identification codes at Col. 9, lines 12-29 
and Col. 16, lines 20-50, and Kilgore at Col. 3, lines 56-67 and Col. 4, lines 1-65, the Applicant 
was unable to find any such teaching in these references at these locations. Instead, these 
sections of Bennett and Kilgore appear to relate to tables having different types of data fields 
and/or identification numbers associated with different tables, as is typically done in normalized 
databases. 

CLAIM 20 

Claim 20 is a new independent claim, characterizing the invention in an alternate manner, 
that is believed allowable for the same reasons as noted above in regards to Claims 1-19. 
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CONCLUSION 

For the reasons set forth above, it is believed that the present case is in a condition for 
allowance, and the Applicant respectfully requests a Notice of Allowance at this time. 

As Applicant has addressed every objection and rejection raised by the Examiner, it is 
respectfully requested that Examiner reconsider rejection of claims 1 -19 and pass claims 1-20 to 
issue. 

Applicant hereby petitions for a one-month extension of time in order to file an 
Amendment and Response on the above-identified application. The fee of $55.00 required under 
37 CFR 1.17(a) is enclosed. 

If any additional extension of time for the accompanying response is required, applicant 
requests that this paper be considered a petition therefor. 

The Commissioner is authorized to charge any fees under 37 CFR 1.17(a) to (d), which 
may be required to Deposit Account No. 13-0235. 


Respectfully submitted, 



Jj)>hn A. Kramer 
Registration No. 46,302 
Attorney for Applicant 


McCormick, Paulding & Huber LLP 
CityPlace II, 185 Asylum Street 
Hartford, CT 06103-3402 
(860) 549-5290 
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